Stream recording assumes an application device, e.g. a settop box, connected to a DVD Streamer. Both devices are connected via e.g. an IEEE1394 (IEC 61883) interface including transmitting and receiving firmware.
Stream Data include one or more ‘Stream Objects’ which each can be stared as a ‘Program Stream’ as described in ISO/IEC 13818-1, Systems.
The following abbreviations are used in the description: APAT: application packet arrival time, ATS: application timestamp, AU: access unit, AUD: AU data, AUELL: access unit end location list, AUEM: access unit end map, AULL: access unit location list, AUSLL: access unit start location list, AUSM: access unit start map, DTS: decoding timestamp, DVD: digital versatile disc, DVD RTRW: DVD realtime rewritable, DVD VR: DVD video recording, EPG: electronic program guide, IAPAT: incremental application packet arrival time, MAPL: mapping list, LB: logical block, PAT: packet arrival time, PES: packetised elementary stream, PTS: presentation timestamp, SCR: system clock reference, SOB: stream object, SOBU: stream object unit, STB; set top box, S_PCK: stream pack, TOC: table of content.
A SOB can be terminated by a program_end_code. The value of the SCR field in the first pack of each SOB may be non-zero. A SOB contains the Stream Data packed into a sequence of Stream Packs. Stream data can be organised as one elementary stream and are carried in PES packets with a stream_id.
In Stream recording, the application performs its own padding so that the pack length adjustment methods of DVD-ROM Video or RTRW need not to be used. In Stream recording it is safe to assume, that the Stream packets will always have the necessary length.
Invention
The invention allows to realise Access Units. The resulting AUs have a resolution range from 2 SOBUs up to ‘application packet’ exact. The precision depends on the used DVD Streamer, i.e. whether the DVD Streamer knows the application and e.g. how much RAM memory is available. Therefore the precision depends on the design of the manufacturer. Each SOB contains its own AU data. This AUD consists of a general information, one or two coarse lists and one or two fine lists.
The coarse list is called the Access Unit Start Map AUSM. The AUSM consists of N flags (N is the number of SOBUs of this SOB). Each flag belongs to one SOBU. The flag indicates that:                an AU points into the corresponding SOBU or into the next SOBU;        no corresponding AU exists for that flag.        
A fine list is called the Access Unit Location List AULL and contains the exact locations of the application packets of all AUs. For each AU indicating AUSM/AUEM flag there exists one location information inside AULL.
Two kinds of AULLs exist:
The part inside the AULL containing the start location is called the Access Unit Start Location List AUSLL. The part inside the AULL containing the end location is called the Access Unit End Location List AUELL.
The complete AU information of an SOB consists of either                the sector & application packet location of the start of the AU and        the sector & application packet location of the end of the data which starts at the AU (e.g. the end of the I-frame) and        the PTS of the AU        or        the start APAT of the AU        the end APAT of the AU (e.g. the end of the I-frame) and        the PTS of the AU        or        the start ATS of the AU the Access Unit End Map AUEM of the AU (for the end ATS of the AUs)        the end ATS of the AU, based on AUEM, not AUSM, and        the PTS of the AU.        
It is possible to have a subset only of the above values, e.g. AUSM or AUSM and AUEM.
It is one object of the invention to disclose a method and a recorder for implementing trickplay modes in a data stream recorder. This object is achieved by the features disclosed in claims 1 and 7.
A trickplay mode, e.g. fast forward, is performed by selecting the desired AUs, e.g. each second AU, via AUSM/AUEM. The generation of AUSM, AUEM, AUSLL and AUELL during SOB recording is optional, i.e. is a matter of the manufacturer. The use of AUSM, AUEM, AUSLL and AUELL for trickplay modes is also optional. However, it is mandatory to update AUSM, AUEM and AULL in the case of editing. FIGS. 3 to 5 show three examples.
The DVD Streamer specification defines the syntax of the AUs, not the generation or use of the AUs. However, here are some examples for how to generate AUSM/AUEM and AULL:                A) The application device sends after transmission of the stream special data which contain a list of AU as APATs, i.e. each APAT of the list is the APAT of one of the just recorded application packets. The streamer must assign each APAT to the corresponding application packet:                    A high end streamer generates a special list during stream recording. This list contains the APAT values of each recorded application packet and the corresponding location in the stream, e.g. sector No. and application packet No. When the application sends the AU list as a list of APATs, the streamer is able to generate all lists: AUSM/AUEM (SOBU accurate) and AULL.            A standard streamer has not enough memory to generate a list with APATs and application packet location information inside the local RAM. Therefore, in this case the streamer will generate only the AUSM (2 SOBU accurate), but not the AUEM and AULL. After that, a high end streamer could generate therefrom the accurate AULL and AUEM (SOBU accurate) and could refine AUSM SOBU accurate, e.g. during an idle mode of this high end streamer.                        B) The streamer contains dedicated hardware to parse the incoming stream, i.e. the application is known by the streamer. This parser recognises automatically Access Units like I-pictures. With such additional hardware AUSM/AUEM (SOBU accurate) and AULL can be easily generated during stream recording.        C) The application uses special digital interface commands to mark an application packet as AU during transmission of the stream to the streamer. Then the streamer is able to generate AUSM/AUEM and AULL in parallel during stream recording if the digital interface is defined accordingly.        D) The application knows nothing about the streamer. In this case AUs will not be generated. After that a high end streamer can generate the missing AUSM/AUEM (SOBU accurate) and AULL, e.g. during idle mode of the streamer.        
Trickplay modes can be applied with or without end of AU information.
Without end of AU information:
The trickplay mode, e.g. fast forward, is performed by searching for the desired AUs, e.g. each second AU, inside the AUSM. If existing, with AULL the exact location of the first application packet of the AU is known. Without AULL, the streamer assumes that the AU is located anywhere in the SOBU indicated by AUSM or in the following SOBU. The streamer jumps to this position and starts the transmission of the application packets to the application with the first application packet of this SOBU. The streamer stops the transmission after having transmitted a fixed amount of data, e.g. 1.8 Mbit or until the next AU, and jumps to the next desired AU. If the streamer knows the application it can parse the stream during transmission of the AU and will stop the transmission when the end of the AU is reached, e.g. the end of an I-picture.
If the stream contains AU flags (AU start/AU end), then the transmission of the AU can also be performed application packet accurate.
With end of AU information:
The only difference to the first alternative is that, if the AULL exists, the transmission of an AU to the application device stops with the transmission of the last application packet of the AU.
Bitstream data (start and end marks) and navigation data (for AUSM, AUEM, AULL) are stored on the disc separately, i.e. in different files.
In principle, the inventive method is suited for implementing trickplay modes in a bitstream recorder, wherein the bitstream is organised in stream objects and access to the bitstream is performed using access units and access unit information is attached to the stream objects of the bitstream and to navigation data to be recorded, and wherein said access unit information includes an access unit start map, and optionally an access unit end map, which are used in the trickplay modes together with the navigation data for access to the bitstream.
In principle, the inventive bitstream recorder is suited for implementing trickplay modes, wherein the bitstream is organised in stream objects and access to the bitstream is performed using access units and access unit information is attached to the stream objects of the bitstream and to navigation data to be recorded, and wherein said access unit information includes an access unit start map, and optionally an access unit end map, which are used in the trickplay modes together with the navigation data for access to the bitstream.
Advantageous additional embodiments of the invention are disclosed in the respective dependent claims.